Static Analysis Group (Archived) — ABacchi035478 (Community Member) asked a question.
What is your pactice of rescanning applications? Have you found a way to automate it?
I want to rescan existing apps often without re-uploading because in theory the static analysis engine updates and might find a new flaw in the code that it didn't before.
Notes from help: https://help.veracode.com/reader/wySvh2U7LWNYqeVS7PQm_g/q26buAAqLWQ11NeA2LCkYQ
"You cannot rescan without amending the module selection."
Why can't you kick off a rescan without amending the module selection?
.png){kind=logo}
As far as rescanning an application we have found there is always a chance of finding new flaws every time you rescan, regardless if the scanner or code is updated. Rescanning is a good practice, we always reload and recompile changed source on every scan.
We have not automated anything.
Scanning "early and often" should alleviate concerns about new flaws introduced as a result of the static scan engine. It gives the developer fast feedback and allows him/her to focus on the current iteration on which they are working.
I encourage setting up automated scans. There are many build tools with which Veracode integrates (think ADO, Jenkins, Bitbucket, Gitlab, etc). It is also possible to develop a script to submit scans because Veracode makes their api's callable (think powershell, curl, bash).
Automated scans can be set up by schedule, by release, by build, whatever makes sense to the team. I prefer the team to get results as soon a possible. This DevOps principle is also applicable to Code Security scanning as well. Frequent scans equates to a smaller amount of code deltas and encourages developers to fix their flaw immediately, if one is identified.
I get it that you don't want to upload the full code upon every change due to time constraints, multiple developers and multiple streams, etc. You have to figure out what works best for each team and for each code base ... then automate. An option could be to implement a sandbox strategy to shorten the window ( or separate developers, or test new strategies, or test branches, etc) and conduct a policy scan not as often ... but still often enough,
excellent points- yes the eventual plan is to automate the scan and schedule it with uploads etc so this is very helpful
Hi @ABacchi035478 (Community Member) just to chime in here from the Veracode product team perspective - the intention of the rescan feature is primarily to let users who have made a mistake with their module selection to easily change it without needing to restart the entire process.
We don't retain uploaded application files longer than ~60 days, so the overall window for performing a rescan on the files that we have stored is relatively short, and with the pace of development many organizations are doing, their code has probably changed a lot in that time frame. As @@DeCaPa (Community Member) mentions - automating scanning is one way to ensure that you're always testing the latest build of your applications.
Hope that this clarifies!
Yes thats a great clarification and helps me understand how to position the culture of "Rescanning". I read in the Veracode 10 report that teams who scan often also burn down more security debt as well.